Анализ и оптимизация деятельности фирмы «Медиаотражение» в г. Миассе.
ПОЯСНИТЕЛЬНАЯ ЗАПИСКА К КУРСОВОМУ ПРОЕКТУ ПО
ДИСЦИПЛИНЕ: Анализ и оптимизация бизнес-процессов

В работе приводится анализ и оптимизация деятельности фирмы «Медиаотражение» в г. Миассе, поиск наиболее рентабельных путей развития.
В курсовом проекте показан процесс построения моделей, описывающих бизнес-процессы предприятия, информационные потоки, документооборот, проверки данных моделей на адекватность и соответствие правилам семантики.
На основе построенных моделей анализируется деятельность фирмы и принимаются решения по улучшению работы, повышению рентабельности через изменение основных бизнес-процессов.
Также в рамках курсового проекта происходит знакомство с функциональными возможностями ARIS Toolset версии 6.2.

Введение 5
Комплексные модели экономических систем и процессов фирмы «Медиаотражение» 6
Организационная диаграмма (Organization chart) 6
Диаграмма целей (Objective diagram) 8
Дерево функций (Function Tree) 10
Диаграмма цепочек добавленного качества (Value added chain diagram) 12
Цепочка процесса, управляемого событиями (extended Event Driven Process Chain) 15
Диаграмма структуры постоянных затрат (Cost category diagram) 18
Модель технических терминов (Technical term models) 19
Дерево продуктов/услуг (Product/Service Tree) 21
Семантическая проверка 23
Организационная диаграмма (Organization chart diagram) 23
Модель технических терминов (Technical term models) 23
Событийная цепочка процесса (extended Event-Driven Process Chain) 24
Проверка моделей на адекватность 25
Анализ и оптимизация моделей БП (eEPC-диаграммы) 26
Функциональные возможности ARIS Toolset 27
ARIS Variant 27
ARIS Chart 30
ARIS Animation 31
ARIS Script Wizard 38
Скрипт «Данные сотрудников.rso» 38
Отчет 41
Заключение 43
Приложение №1. Семантическая проверка диаграмм 44
Приложение №1.1. Организационная диаграмма 44
Приложение №1.2. Модель технических терминов 48
Приложение №1.3. eEPC 56
Приложение № 2. Проверка на адекватность моделей. 62
Приложение № 2.1. Existence Rules. 62
Приложение № 2.2. Allocation Rules. 63
Приложение № 2.3. ARIS Analysis 65
Информационные разрывы 65
Организационные разрывы 66
Список используемой литературы 67

Внимание!
Это ОЗНАКОМИТЕЛЬНАЯ ВЕРСИЯ работы №3362, цена оригинала 500 рублей. Оформлена в программе Microsoft Word

Введение
Фирма «Медиаотражение» находиться в городе Миассе по улице Макеева, дом 20. Она занимается созданием, поддержкой и продвижением веб-сайтов.
Фирма была создана в 2005 году Голубевым А. Т. Сейчас штатная структура фирмы насчитывает восемь человек: генеральный директор Голубев А. Т., также являющийся арт-директором; технический директор Жанна Рутковская, являющаяся также начальником отдела программистов; один программист, два дизайнера и технолога.
Фирма состоит из состоит из 5 отделов: дирекция, отдет программистов, отдел дизайнеров, технический отдел и отдел менеджеров.
Главной задачей, стоящей перед фирмой, является удовлетворение ожиданий и требований заказчиков.
В фирме активно применяются современные методы разработки и новые технологии, что позволяет эффективно конкурировать на рынке.

Комплексные модели экономических систем и процессов фирмы «Медиаотражение»
Организационная диаграмма (Organization chart)
«Организационная диаграмма» (Organizational Chart) предназначена для описания организационно – штатной структуры предприятия. То есть она показывает, из каких подразделений предприятие состоит, какие сотрудники входят в каждое из подразделений, какие отношения должностной подчиненности между ними есть.
На данной диаграмме представлена штатная структура фирмы «Медиатотражение».
Управляет фирмой «Генеральный директор» Голубев А. Т., по совместительству «Арт-директор».
Фирма делится на отделы: «Дирекция», «Отдел дизайнеров», «Технический отдел», «Отдел программистов». Каждый отдел возглавляет начальник: Голубев А. Т., так же являющийся «Арт-директором» «Отдела дизайнеров», «Начальник отдела программистов» Жанна Рутковская, начальник «Технологического отдела» «Главный технолог» Макеев В. А. В штат отделов дизайнеров, программистов и технологов входят группы соответственно «Дизайнеры» и «Программисты» и «Веб-технологи».
С помощью «Организационной диаграммы» (Organization chart) детализируется объект «Организационная единица» «Медиаотражение», который представлен в диаграмме «Цепочка добавленного качества» (Value added chain diagram). Объекты «Организационная единица»: «Технический отдел», «Отдел дизайнеров», «Отдел программистов», «Технический отдел», «Бухгалтерия» — объекты «Должность»: «Главный технолог», «Начальник дизайнерского отдела», «Начальник отдела программистов» — встречаются в диаграммах:
• «Цепочка добавленного качества» (Value added chain diagram)
• «Цепочка процесса, управляемого событиями» (extended Event Driven Process Chain)
• «Диаграмма информационных потоков» (Informational flow diagram)
• «Диаграмма окружения функций» (Function allocation diagram)
• «Диаграмма окружения продукта» (Product allocation diagram)
• «Диаграмма движения (обмена) продуктами/услугами» (Product/Service exchange diagram)
• «Технические ресурсы» (Technical resourse).
Типы связей, используемые «Организационной диаграмме» (Organizational Chart):
1. Is composed of — Состоит из
2. Is located at – Располагается
3. Is technical superior to — Является техническим руководителем
4. Is disciplinary superior to — Является непосредственным руководителем
5. Is technical superior to — Является техническим руководителем
6. Is organization manager for — Является организационным управляющим.

Диаграмма целей (Objective diagram)
«Диаграмма целей» (Objective diagram) используется для описания целей организации и построения их иерархии.
«Диаграмма целей» (Objective diagram) детализируется объект цель «Получить прибыль на рынке веб-разработки» из диаграммы «Цепочка добавленного качества» (Value added chain diagram).
В диаграмме описывается главная цель и подцели, которых хочет достигнуть фирма «Медиаотражение».
Главной целью является «Получить прибыль на рынке веб-разработки». Эта цель подразделяется на подцели, помогающие достигнуть главной цели:
• Создание новых веб-ресурсов, для выполнения которой необходимо «Соблюдение договора» и «Консультирование», где критическим фактором успеха выступает «Недостаток ресурсов»
• «Сопровождение старых клиентов», для выполнения которых необходим «Приоритет на решение срочных вопросов», где критическим фактором успеха так же является «Недостаток ресурсов»
• «Привлечение новых клиентов», для выполнения которой необходимо «Изучение рынка» и «Гибкое ценообразование», где критическим фактором успеха является «Большая конкуренция»
• «Повышение качества работ», для выполнения которого необходимы «Постоянный контроль качества», «Введение внутрикорпоративных стандартов», а критическим фактором успеха выступают «Несоблюдение внутрикорпоративных стандартов» и «Долгий ввод в рабочий процесс новых сотрудников».
Объекты цели используются также в диаграммах:
• «Дерево продуктов/услуг» (Product/Service Tree)
• «Диаграмма окружения функций» (Function allocation diagram)
• «Диаграмма окружения продукта» (Product allocation diagram).
Типы связей, используемые в «Диаграмме целей» (Objective diagram):
1. Belongs to – Принадлежит
2. Supports – Поддерживает
3. Is critical factor for – Является критическим фактором для.

Рисунок 2. «Диаграмма целей» (Objective diagram)

Дерево функций (Function Tree)
Модель «Дерева функций» предназначена для представления иерархической структуры функций. Function tree отражает статистические связи между функциями и позволяет ответить на вопросы:
• зависят ли функции друг от друга
• какая из функций важнее
• существуют ли родительские, дочерние отношения между функциями?
Диаграмма «Дерево функций» (Function Tree) детализирует функцию «Создание и поддержка веб-ресурсов» из диаграммы «Цепочки добавленного качества» (Value added chain diagram).
В данной диаграмме описываются функции необходимые для создания веб-ресурса.
Создание веб-ресурса включает в себя:
• «Получение заказа»: «Подписание договора», «Разработку концепции» и «Разработку технического задания», на основе которого возможны «Создание дизайна», «Программирование», «Вёрстка» и «Сборка готового веб-ресурса», так же детализирующиеся более подробно.
• «Пооддержку»: «Соблюдение договора», «Приоритет на решение сложных вопросов» и «Консультирование»
Данные функции встречаются в диаграммах:
• «Цепочки добавленного качества» (Value added chain diagram);
• «Цепочка процесса, управляемого событиями» (extended Event Driven Process Chain);
• «Диаграмма информационных потоков» (Informational flow diagram);
• «Диаграмма окружения функций» (Function allocation diagram).
Типы связей, используемые в диаграмме «Дерево функций» (Function Tree):
1. Is process-oriented superior — Подчиняется по процессу.

Рисунок 3. Диаграмма «Дерево функций» (Function Tree)

Диаграмма цепочек добавленного качества (Value added chain diagram)
«Диаграмма цепочек добавленного качества» (Value added chain diagram) описывает функции организации, которые непосредственно влияют на реальный выход ее продукции. Эти функции создают последовательность действий, формируя добавленные значения: стоимость, количество, качество и т.д.
На данной диаграмме представлен весь процесс деятельности фирмы.
Главной функцией фирмы, организационная структура которой описана с помощью «Организационной диаграммы» (Organizational Chart), является создание и поддержка веб-ресурсов, описанной с помощью диаграммы «Дерево функций» (Function Tree), цель которой получение прибыли на рынке веб-разработки, описана с помощью «Диаграммы целей» (Objective diagram). Эта функция делиться на ряд подфункций:
• Получение заказа, детализируемая диаграммой «Цепочка процесса, управляемого событиями» (extended Event Driven Process Chain), которым занимается технический отдел
• Создание дизайна, которым занимается отдел дизайнеров, и имеющий на выходе продукт «Шаблон дизайна», детализируемый в «Диаграмме окружения продукта» (Product allocation diagram), который нужен для выполнения следующей функции
• Написание программного кода, детализируемая диаграммой «Диаграмма окружения функций» (Function allocation diagram), которым занимается отдел программистов, и имеющий на выходе продукт «Программный код»
• Вёрстка, которой занимается технический отдел, имеющая на выходе продукт «Макет»
• Сборка готового веб-ресурса, которой занимается технический отдел, который имеет на выходе продукт веб-ресурс, детализируемый с помощью диаграммы «Дерево продуктов/услуг» (Product/Service Tree) и технический термин «Интернет-проект», детализируемый с помощью «Модели технических терминов» (Technical term models)
Для выполнения этих функций необходимы также «Концепция» и различные знания в сфере программирования.
В свою очередь у подфункций существуют свои подфункции. Так подфункция «Получение заказа» делиться на «Поиск клиентов», «Подписание договора», «разработка технического задания», где необходимо само «Техническое задание», и «Разработка технического задания», которая детализируется в «Диаграмме информационных потоков» (Informational flow diagram). А подфункция «Сборка готового веб-сайта» делиться на:
• «Проверку качества»
• «Утверждение заказчиком»
• «Расчет за выполненные работы», который проводит «Бухгалтерия»;
Все объекты используемые в диаграмме будут использоваться в остальных моделях.
Типы связей, используемые в «Диаграмме цепочек добавленного качества» (Value added chain diagram):
1. Supports – Поддерживает
2. Is technical responsible for — Отвечает за техническую часть
3. Is process-oriented superior — Подчиняется по процессу
4. Is predecessor of – Предшествует
5. Has output of — Имеет на выходе
6. Is input for — Является входом для

Цепочка процесса, управляемого событиями (extended Event Driven Process Chain)
Событийная цепочка процесса (кратко — модель или диаграмма eEPC). Модель предназначена для детального описания процессов, выполняемых в рамках одного подразделения, несколькими подразделениями или конкретными сотрудниками. Она позволяет выявлять взаимосвязи между организационной и функциональной моделями. Модель eEPC отражает последовательность функциональных шагов (действий) в рамках одного бизнес-процесса, которые выполняются организационными единицами, а также ограничения по времени, налагаемые на отдельные функции.
Модель eEPC детализирует функцию «Получение заказа» из диаграммы «Цепочка добавленного качества» (Value added chain diagram).
На данной диаграмме представлен процесс Получения заказа.
Фирма «Получает заказ» от «Заказчика» при участии «Менеджмента». Заявка «Заказчика» поступает в «Дирекцию» при участии «Юриста» и «Заказчика» подписывается «Договор». Фирма разрабатывает «Концепцию». Если «Заказчик» предоставляет «Техническое задание», то «Главный технолог» получает его у «Заказчика», иначе фирма разрабатывает «Техничесвое задание» при участии всех отделов, затем согласует его с «Заказчиком» при участии «Главного технолога». Когда «Техническое задание» согласовано, начинаются работы. Заявка «Заказчика» удовлетворяется.
Такие функции как:
• Получение заказа
• Разработка технического задания
• Подписание договора
присутствуют в диаграмме «Дерево функций» (Function Tree). Функция «Разработка технического задания» детализируется с помощью диаграммы «Информационных потоков» (Informational flow diagram). Объект «Должность»:
• Главный технолог
встречаются в диаграммах:
• «Организационная диаграмма» (Organizational Chart);
• «Технические ресурсы» (Technical resourse).
Организационные единицы
• Технический отдел
• Отдел программистов
есть на диаграммах:
• «Цепочки добавленного качества» (Value added chain diagram)
• «Информационных потоков» (Informational flow diagram)
• «Организационная диаграмма» (Organizational Chart)
• «Диаграмма движения (обмена) продуктами/услугами» (Product/Service exchange diagram).
Типы связей, используемые в eEPC:
1. Activates – Активизирует
2. Is predecessor of – Предшествует
3. Creates – Порождает
4. Leads to – Формирует
5. Is technically responsible for — Отвечает за техническую часть
6. Creates output to — Создается на выходе
7. Is used by – Используется;
8. Is input for — Является входом для.

Рисунок 5. «Цепочка процесса, управляемого событиями» (extended Event Driven Process Chain)

Диаграмма структуры постоянных затрат (Cost category diagram)
На диаграмме «Структура постоянных затрат» (Cost category diagram) представлена структура постоянных затрат фирмы.
Постоянные затраты фирмы «Медиаотражение» складываются из:
• Коммунального обслуживания: Плата за электроэнергию, Плата за телефон; Плата за интернет
• Маркетинговые и другие административные затраты: Административные затраты, Маркетинговые исследования;
• Ежепериодная плата за услуги по договорам со сторонними организациями: Плата за аренду, Плата за охрану, Плата за уборку;
• Обслуживание и ремонт основных средств: Обслуживание оборудования, Ремонт оборудования, расходные материалы.
Типы связей, используемые в диаграмме «Структура постоянных затрат» (Cost category diagram):
1. Is superior — Имеет в подчинении.
Рисунок 6. Диаграмма структуры постоянных затрат (Cost category diagram)

Модель технических терминов (Technical term models)
«Модель технических терминов» (Technical term models) позволяет манипулировать различными терминами как синонимами, дает возможность поддерживать отношения между объектами в моделях данных.
В данной модели представлен детализированный технический термин «Интернет-проект» из диаграммы «Цепочка добавленного качества» (Value added chain diagram).
Технический термин «Интернет-проект» включает в себя «Виды услуг», «Виды продукта»и «Состояния работ». Это обобщенные термины. Если рассматривать более подробно, то «Виды услуг», оказываемые фирмой это:
• Разработка
• Продвижение
• Поддержка
«Виды продукта»:
• Сайт-визитка;
• Корпоративный сайт
• Интернет-магазин
• Отраслевой портал
• Нишевой портал
• Промо-сайт
а «Состояния работ» работ могут быть:
• Завершенные
• Незавершенные
• «Замороженные», т.е. временно приостановленные.
Все виды услуг и продуктов также встречаются в диаграммах «Дерево продуктов/услуг» (Product/Service Tree) и «Цепочки добавленного качества» (Value added chain diagram).
Типы связей, используемые в «Модели технических терминов» (Technical term models):
1. Depicts – Отображает.
Рисунок 7. «Модель технических терминов» (Technical term models)

Дерево продуктов/услуг (Product/Service Tree)
«Дерево продуктов/услуг» (Product/Service Tree) предназначено для представления продукции в виде составляющих ее частей.
С помощью диаграммы «Дерево продуктов/услуг» (Product/Service Tree) детализируется объект «Продукт» «Веб-ресурс» из диаграммы «Цепочек добавленного качества» (Value added chain diagram).
На диаграмме «Дерево продуктов/услуг» (Product/Service Tree) представлены те продукты и услуги, которые производит и предоставляет фирма «Медиаотражение».
«Веб-ресурс» — это главный продукт выпускаемый фирмой. Он подразделяется на «Услуги»:
• Разработка
• Продвижение
• Поддержка
и на «Продукты»:
• Сайт-визитка;
• Корпоративный сайт;
• Интернет-магазин
• Отраслевой портал
• Нишевой портал
• Промо-сайт
Целью создания Продукта «Веб-ресурс» является «Получение прибыли на рынке веб-разработки», встречающейся также в диаграмме целей.
Типы связей, используемые в диаграмме «Дерево продуктов/услуг» (Product/Service Tree):
1. Supports – Поддерживает
2. Consists of — Состоит из
3. Is input for — Является входом для.
Рисунок 8. «Дерево продуктов/услуг» (Product/Service Tree)

Семантическая проверка
Все модели были проверены в модуле семантической проверки (ARIS Semantic Check) согласно соответствующим правилам структуры (Structure Rules).
После проведения семантической проверки те модели, в которых были выявлены ошибки, удалось исправить, а в курсовом проекте показать модели до и после исправления, а также вставить отчет Semantic Report.
Отчеты о результатах семантической проверки моделей представлены в Приложении № 1.
Были выявлены ошибки в трех моделях.
Организационная диаграмма (Organization chart diagram)
Рассмотрим организационную диаграмму «Организационная диаграмма». После семантической проверки были выявлены следующие ошибки:
— организационная единица «Медиаотражение» имеет исходящие соединения разных типов (is composed of, is superior),
— данная модель имеет различные типы связей.
Отчет о семантической проверке организационной диаграммы представлен в Приложении № 1.1.
Модель технических терминов (Technical term models)
После семантической проверки модели технических терминов была выявлена ошибка: объект «Замороженные» не имеет связи с каким-либо объектом.
Отчет о семантической проверке модели технических терминов представлен в Приложении № 1.2.

Событийная цепочка процесса (extended Event-Driven Process Chain)
Рассмотрим диаграмму eEPC «Регламент продажи металлопроката», где после семантической проверки также были обнаружены ошибки. В данной модели нарушены правила «Each path must begin and end with an event», «All functions/events have only one incoming/outgoing connection», «No XOR/OR after event possible» и «Order at the operator must be preserved».
Отчет о семантической проверке событийной цепочке процесса представлен в Приложении № 1.3.

Проверка моделей на адекватность
1. В моделях процессов имеются выходы (документы, файлы, продукция), которые не используются другими функциями в этом же процессе «Техническое задание», «Концепция».
2. В eEPC-диаграмме не представлена организационная единица «Менеджмент», присутствующий на организационной диаграмме. Не представлены организационные единицы, которые задействованы в представленных моделях процессов: должности «Заказчик» и «Юрист». Отчет о семантической проверке (Existence Rules) представлен в Приложении № 2.1.
3. В процессах модели eEPC есть функции, исполнитель которых не указан или его трудно определить. Отчет о семантической проверки по правилам взаимосвязи объектов для eEPC (Allocation Rules for eEPC) представлены в Приложении № 2.2.
4. В eEPC-модели «Получение заказа» большинство функций не автоматизировано.
5. Анализ процессов на информационные и организационные разрывы был проведен с помощью модуля ARIS Analysis. Отчеты представлены в Приложении № 2.3.
6. В организационных диаграммах есть руководители, имеющие в подчинении менее 3 человек и нет имеющих более 5-6 подразделений.
7. Функции, дублирующие друг друга (или функции со схожими названиями), но выполняемые различными лицами в различных процессах не имеются.

Анализ и оптимизация моделей БП (eEPC-диаграммы)
По построенным моделям бизнес-процессов (БП) (еЕРС-диаграммам) проведем анализ и оптимизацию бизнес-процессов предприятия.
Во-первых, необходимо обратить внимание на систему документооборота, а точнее на использование должностных инструкций (ДИ). Каждый работник должен иметь свою ДИ, которая бы регламентировала его действия, исключая выполнение чужой или ненужной работы.
Во-вторых, многие функции и процессы, показанные в БП предприятия нужно автоматизировать.

Функциональные возможности ARIS Toolset
ARIS Variant
Модуль ARIS Variant предназначен для создания вариантов одной и той же модели, соответствующих различным характеристикам, различным начальным условиям и состояниям моделируемого объекта. Это позволяет рассматривать и анализировать условия деятельности предприятия и состояния его объектов, их структуры с различных точек зрения. Удобным может оказаться сравнение исходной модели (Master Model) и ее варианта (вариантов) (Variant Model) по нескольким критериям. Для головной организации использование этого модуля может оказаться полезным при построении на основе описанных ее основных процессов вариантов этих процессов для дочерних подразделений и филиалов (например, процессы коммерческого банка могут быть исходными для создания вариантов процессов в его филиалах банках, в которых эти процессы практически повторяют с небольшими вариациями деятельность головного банка).
Рассмотрим еЕРС-диаграмму «Получение заказа». Построим для нее модель-вариант.

Рисунок 9. Правильная eEPC-модель

Рисунок 10. Неправильный вариант главной eEPC-модели
В правильном варианте отсутствует событие «Не соглавсовано», изменён пакет «Техническое задание» на документ «Техническое задание».

ARIS Chart
Модуль ARIS Chart предназначен для создания графических диаграмм, описывающих различные аспекты разработанных моделей. Такие диаграммы благодаря трехмерному представлению и использованию тени для объектов обеспечивают эффективный анализ информации, заложенной в моделях, и их взаимосвязей. Они могут также применяться в различных презентациях. Для этой цели в ARIS Chart включено большое число типов графических диаграмм, которые можно изменять в широких пределах, создавая новые шаблоны. Кроме того, предусмотрена возможность для переноса построенных диаграмм в другие приложения.
Диаграммы могут быть построены не для всех элементов ARIS. Система сама разрешает или не разрешает запускать ARIS Chart для выбранного элемента. Для построения диаграмм используются данные, записанные в определенные атрибуты объектов.
Выберем функцию «Программирование» для построения графика ARIS Chart. Построим график издержек для данной функции. На этой диаграмме видно, что общие издержки равны 12000 руб., материальные – 200 руб., а на оплату работы персонала – 10000 руб.
ARIS Animation
После построения моделей можно использовать еще одну функциональность ARIS Toolset –– анимацию, которая особенно удобна для процессно-ориентированнного обучения. При использовании анимации модель БП можно представить в динамике и проанализировать такие параметры БП, как время и стоимость выполнения. При этом могут вызываться присвоенные документы, приложения и Intranet/Internet связи. Процесс анимации может быть задокументирован как бизнес-случай и сохранен под собственным именем с целью возможного дальнейшего использования.
Анимация и бизнес случаи используются для следующих целей: просмотра динамической логики БП, упрощения процесса моделирования логически сложных БП, анализа сроков и затрат для одного, нескольких или всех БП производственной деятельности предприятия, оценки минимальных (максимальных) материальных затрат и времени исполнения различных альтернативных БП, визуализации интегрированных документов, прикладных систем и Intranet/Internet страниц в БП.
Анимации могут быть подвергнуты все модели БП типа еЕРС, еЕРС с материальным потоком, производственные БП, офисные БП, БП верхнего уровня (VAD-диаграммы), PCD и PCD с материальным потоком, в которых рассматриваются функции, события, правила, связи и типы объектов интерфейса процесса.

Рисунок 11. eEPC: Получение заказа (1 период)
Рисунок 12. eEPC: Получение заказа (2 период)
Рисунок 13. eEPC: Получение заказа (3 период)

Отчет по стоимости БС eEPC-модели «Получение заказа» за 1 период (на единицу продукции).
Function TC MC PC oC
Есть техническое задание? 10 RUB 10 RUB
Начало работ 30000 RUB 2000 RUB 25000 RUB 3000 RUB
Подписание договора 0 RUB 0 RUB 0 RUB 0 RUB
Получение заказа 510 RUB 10 RUB 500 RUB
Получение технического задания у заказчика 100 RUB 100 RUB
Разработка концепции 150 RUB 100 RUB 50 RUB
Sum 30770 RUB 2120 RUB 25550 RUB 3100 RUB
Отчет по времени БС eEPC-модели «Получение заказа» за 1 период (на единицу продукции).
Function PT OT WT SpF
Есть техническое задание? 30 Minute(s) 0 Minute(s) 0 Minute(s) 30min.
Начало работ 20 Day(s) 10 Minute(s) 10 Minute(s) 20D. 20min.
Подписание договора 3 Hour(s) 1 Day(s) 30 Minute(s) 1D. 3h. 30min.
Получение заказа 3 Hour(s) 30 Minute(s) 1 Hour(s) 4h. 30min.
Получение технического задания у заказчика 10 Minute(s) 10 Minute(s) 0 Minute(s) 20min.
Разработка концепции 4 Day(s) 2 Hour(s) 0 Minute(s) 1D. 2h.
Sum 25D. 6h. 40min. 1D. 2h. 50min. 1h. 40min. 23D. 11h. 10min.
Отчет по стоимости БС eEPC-модели «Получение заказа» за 2 период (на единицу продукции).
Function TC MC PC oC
Есть техническое задание? 10 RUB 10 RUB
Начало работ 30000 RUB 2000 RUB 25000 RUB 3000 RUB
Подписание договора 700 RUB 100 RUB 500 RUB 100 RUB
Получение заказа 510 RUB 10 RUB 500 RUB
Разработка концепции 150 RUB 500 RUB 50 RUB
Разработка технического задания 1050 RUB 450 RUB 1000 RUB
Согласование технического задания с заказчиком 500 RUB 1000 RUB
Sum 30770 RUB 2650 RUB 24000 RUB 5770 RUB
Отчет по времени БС eEPC-модели «Получение заказа» за 2 период (на единицу продукции).
Function PT OT WT SpF
Есть техническое задание? 30 Minute(s) 0 Minute(s) 0 Minute(s) 30min.
Начало работ 20 Day(s) 10 Minute(s) 10 Minute(s) 20D. 20min.
Подписание договора 3 Hour(s) 1 Day(s) 30 Minute(s) 1D. 3h. 30min.
Получение заказа 3 Hour(s) 30 Minute(s) 1 Hour(s) 4h. 30min.
Разработка концепции 1 Day(s) 2 Hour(s) 0 Minute(s) 1D. 2h.
Разработка технического задания 2 Day(s) 30 Minute(s) 30 Minute(s) 2D. 1h.
Согласование технического задания с заказчиком 1 Day(s) 1 Hour(s) 0 Minute(s) 1D. 1h.
Sum 19D. 6h. 30min. 1D. 4h. 10min. 2h. 10min. 20D. 12h. 50min.
Отчет по стоимости БС eEPC-модели «Получение заказа» за 3 период (на единицу продукции).
Function TC MC PC oC
Есть техническое задание? 10 RUB 10 RUB
Начало работ 30000 RUB 2000 RUB 25000 RUB 3000 RUB
Подписание договора
Получение заказа 510 RUB 10 RUB 500 RUB
Получение технического задания у заказчика 2000 RUB 100 RUB
Разработка концепции 150 RUB 100 RUB 50 RUB
Sum 35500 RUB 2120 RUB 30180 RUB 3200 RUB
Отчет по времени БС-eEPC-модели «Получение заказа» за 3 период (на единицу продукции).
Function PT OT WT SpF
Есть техническое задание? 30 Minute(s) 0 Minute(s) 0 Minute(s) 30min.
Начало работ 20 Day(s) 10 Minute(s) 10 Minute(s) 20D. 20min.
Подписание договора 3 Hour(s) 1 Day(s) 30 Minute(s) 1D. 3h. 30min.
Получение заказа 3 Hour(s) 30 Minute(s) 1 Hour(s) 4h. 30min.
Получение технического задания у заказчика 10 Minute(s) 10 Minute(s) 0 Minute(s) 20min.
Разработка концепции 4 Day(s) 2 Hour(s) 0 Minute(s) 1D. 2h.
Sum 24D. 6h. 40min. 1D. 2h. 50min. 1h. 40min. 25D. 11h. 10min.
Исходя из полученных данных можно сделать вывод, что стоимость процесса (на единицу выпускаемой продукции) больше в третьем периоде (35500 руб.), меньше всего – во втором периоде (30770 руб.). По времени выполнения (на единицу выпускаемой продукции) самым продолжительным является процесс, выполняемый в третьем периоде (25 дней), а самым коротким – во втором периоде (20 дней). Наибольшие материальные затраты требуются для процесса третьего периода (35500 руб. на ед. продукции), наименьшие материальные затраты – для процесса первого и третьего периода (30770 на ед. продукции). Наиболее трудоемким также является процесс третьего периода, наименьшим в этом же отношении – процесс второго периода.
Таким образом, производить продукцию по варианту, указанному во втором периоде более выгодно для предприятия по стоимостному и временному показателям (их итоговые значения минимальны из всех трех периодов). Наиболее затратным в стоимости и времени является процесс третьего периода Однако, выбор каждого из вариантов процессов должен обуславливаться не только экономической целесообразностью, но и значимостью и приоритетом каждого из процессов в решении локальных и общих целей предприятия (качество выполнения процесса, важность результата процесса для клиента и предприятия, оптимальностью загрузки оборудования в каждом из процессах, степенью квалификации сотрудников и т.д.).
ARIS Script Wizard
Модуль ARIS Script Editor входит в AR/S Toolset и позволяет пользователю создавать собственные скрипты отчетов, соответствующие потребностям компании, в дополнение к скриптам, включенным в пакет ARIS.
Скрипт — это инструкция, которая содержит команды языков Visual Basic и ARIS Basic® Language Capability. Компоненты в ARIS обращаются к скриптам, чтобы обеспечивать пользователя базы данных доступной информацией в форме таблицы или текста. Используя скрипты, созданные мастером скриптов, можно генерировать вывод информации в файлы форматов RTF, HTML и ТХТ.
Механизм создания скриптов Script Wizard позволяет также быстро построить новую программу для генерации отчета. Он реализуется посредством диалоговых окон, перемещаясь по которым пользователь формирует структуру будущей программы.
Напишем с помощью Script Wizard собственный небольшой отчет «Данные сотрудников». Он будет содержать анкетные данные работников фирмы «Медиаотражение». В отчете отобразим следующие данные работников: фамилию, имя, отчество, адрес, телефон и занимаемую работником должность. Данные, выводимые в отчет, будут отсортированы в алфавитном порядке по фамилии работника.
После того как будет создан отчет, необходимо отредактировать программу скрипта с помощью редактора скриптов (Script Editor) для русификации выводимой в отчете информации.
Скрипт «Данные сотрудников.rso»
‘———————————————————
‘ Aris 6 — Report Script, Object
‘———————————————————
‘global declarations
‘ selected language (localeId)
Global g_nLoc As Long
‘ declare the output Object
Global g_oOutFile As Object
‘ this is the main subroutine.
‘ called, when the script is being executed
Sub Main
‘ create and initialize the output Object and variable for selected language
Set g_oOutFile = New OutputClass
g_nLoc = SelectedLanguage
g_oOutFile.Init(SelectedFormat, g_nLoc)
‘definitions of used stylesheets
g_oOutFile.DefineF(«REPORT1″,»Arial»,24,C_BLACK,COLOR_TRANSPARENT,FMT_BOLD Or FMT_CENTER,0,21,0,0,0,1)
g_oOutFile.DefineF(«REPORT2″,»Times New Roman»,14,C_BLACK,COLOR_TRANSPARENT,FMT_LEFT,0,21,0,0,0,1)
‘graphics used in header
Dim pictLeft As New picture
Dim pictRight As New picture
pictLeft.Create(«LogoL.wmf»)
pictRight.Create(«LogoR.wmf»)
‘ Header + Footer
g_oOutFile.BeginHeader()
g_oOutFile.BeginTable(100,C_BLACK,COLOR_TRANSPARENT,FMT_LEFT,0)
g_oOutFile.TableRow()
g_oOutFile.TableCell(«»,26, «Times New Roman»,12,C_BLACK,COLOR_TRANSPARENT,0,FMT_CENTER Or FMT_VCENTER,0)
g_oOutFile.OutGraphic(pictLeft,-1,40,15)
g_oOutFile.TableCell(«»,48, «Times New Roman»,14,C_BLACK,COLOR_TRANSPARENT,0,FMT_CENTER Or FMT_VCENTER,0)
g_oOutFile.Output(ScriptInfo(SCRIPT_TITLE), «Times New Roman»,12,C_BLACK,COLOR_TRANSPARENT,FMT_CENTER,0)
g_oOutFile.TableCell(«»,26, «Times New Roman»,12,C_BLACK,COLOR_TRANSPARENT,0,FMT_CENTER Or FMT_VCENTER,0)
g_oOutFile.OutGraphic(pictRight,-1,40,15)
g_oOutFile.EndTable(«»,100, «Times New Roman»,10,C_BLACK,COLOR_TRANSPARENT,0,FMT_LEFT Or FMT_VCENTER,0)
g_oOutFile.EndHeader()
g_oOutFile.BeginFooter()
g_oOutFile.BeginTable(100,C_BLACK,COLOR_TRANSPARENT,FMT_LEFT,0)
g_oOutFile.TableRow()
g_oOutFile.TableCell(Str$(Date) + » » + Str$(Time),26, «Times New Roman»,12,C_BLACK,COLOR_TRANSPARENT,0,FMT_CENTER Or FMT_VCENTER,0)
g_oOutFile.TableCell(SelectedPath+SelectedFile,48, «Times New Roman»,12,C_BLACK,COLOR_TRANSPARENT,0,FMT_CENTER Or FMT_VCENTER,0)
g_oOutFile.TableCell(«»,26, «Times New Roman»,12,C_BLACK,COLOR_TRANSPARENT,0,FMT_CENTER Or FMT_VCENTER,0)
g_oOutFile.Output(«Page «, «Times New Roman»,12,C_BLACK,COLOR_TRANSPARENT,FMT_CENTER,0)
g_oOutFile.OutputField(FIELD_PAGE, «Times New Roman»,12,C_BLACK,COLOR_TRANSPARENT,FMT_CENTER)
g_oOutFile.Output(» of «, «Times New Roman»,12,C_BLACK,COLOR_TRANSPARENT,FMT_CENTER,0)
g_oOutFile.OutputField(FIELD_NUMPAGES, «Times New Roman»,12,C_BLACK,COLOR_TRANSPARENT,FMT_CENTER)
g_oOutFile.EndTable(«»,100, «Times New Roman»,10,C_BLACK,COLOR_TRANSPARENT,0,FMT_LEFT Or FMT_VTOP,0)
g_oOutFile.EndFooter()
‘ Headline
g_oOutFile.OutputLnF(«»,»REPORT1″)
g_oOutFile.OutputLnF(«Данные сотрудников фирмы Медиаотражение»,»REPORT1″)
g_oOutFile.OutputLnF(«»,»REPORT1″)
‘iterate through oSelectedObjDefs1
Dim oSelectedObjDefs1 As Object
Dim oSelectedObjDefs1Obj As Object
Dim i1 As Long
Set oSelectedObjDefs1 = SelectedObjDefs
oSelectedObjDefs1.Sort(AT_NAME, AT_ADDR, AT_PHONE_NUM, g_nLoc)
For i1 = 0 To oSelectedObjDefs1.Count()-1
Set oSelectedObjDefs1Obj = oSelectedObjDefs1.Get(i1)
‘no object method specified: … writing default
g_oOutFile.OutputLn(oSelectedObjDefs1Obj.Attribute(AT_NAME, g_nLoc).Type +»: «+ Str(oSelectedObjDefs1Obj.Attribute(AT_NAME, g_nLoc).GetValue(TRUE)), «Arial»,10,C_BLACK,COLOR_TRANSPARENT,FMT_LEFT,0)
‘no object method specified: … writing default
g_oOutFile.OutputLn(oSelectedObjDefs1Obj.Attribute(AT_ADDR, g_nLoc).Type +»: «+ Str(oSelectedObjDefs1Obj.Attribute(AT_ADDR, g_nLoc).GetValue(TRUE)), «Arial»,10,C_BLACK,COLOR_TRANSPARENT,FMT_LEFT,0)
‘no object method specified: … writing default
g_oOutFile.OutputLn(oSelectedObjDefs1Obj.Attribute(AT_PHONE_NUM, g_nLoc).Type +»: «+ Str(oSelectedObjDefs1Obj.Attribute(AT_PHONE_NUM, g_nLoc).GetValue(TRUE)), «Arial»,10,C_BLACK,COLOR_TRANSPARENT,FMT_LEFT,0)
‘iterate through oCxnListFilter1
Dim oCxnListFilter1 As Object
Dim oCxnListFilter1Obj As Object
Dim i2 As Long
Set oCxnListFilter1 = oSelectedObjDefs1Obj.CxnListFilter(EDGES_OUT, CT_OCCUPIES)
For i2 = 0 To oCxnListFilter1.Count()-1
Set oCxnListFilter1Obj = oCxnListFilter1.Get(i2)
g_oOutFile.OutputLn(«», «Arial»,10,C_BLACK,COLOR_TRANSPARENT,FMT_LEFT,0)
‘no object method specified: … writing default
g_oOutFile.OutputLn(oCxnListFilter1Obj.TargetObjDef.Attribute(AT_NAME, g_nLoc).Type +»: «+ Str(oCxnListFilter1Obj.TargetObjDef.Attribute(AT_NAME, g_nLoc).GetValue(TRUE)), «Arial»,10,C_BLACK,COLOR_TRANSPARENT,FMT_LEFT,0)
‘no object method specified: … writing default
g_oOutFile.OutputLn(oCxnListFilter1Obj.TargetObjDef.Attribute(AT_TYP6, g_nLoc).Type +»: «+ Str(oCxnListFilter1Obj.TargetObjDef.Attribute(AT_TYP6, g_nLoc).GetValue(TRUE)), «Arial»,10,C_BLACK,COLOR_TRANSPARENT,FMT_LEFT,0)
Set oCxnListFilter1Obj = Nothing
Next i2
Set oCxnListFilter1 = Nothing
Set oSelectedObjDefs1Obj = Nothing
Next i1
Set oSelectedObjDefs1 = Nothing
g_oOutFile.WriteReport(SelectedPath, SelectedFile)
End Sub

Отчет
Данные сотрудников фирмы Медиаотражение
Name: Алексашенко О. Д.
Address: ул. Светлая 25, 1
Telephone number: +79085639274
Name: Артюх Ю. Л.
Address: ул. Жуковского 2, 133
Telephone number: +79518967346
Name: Голубев А. Т.
Address: проспект Октября, 70, 34
Telephone number: +79515714822
Name: Генеральный директор
:
Name: Арт-директор
:
Name: Котеров Д. И.
Address: ул. Инструментальщиков 7, 1
Telephone number: +79028046354
Name: Левенчук А. И.
Address: пр.-т. Октября 18, 14
Telephone number: +79048043800
Name: Макеев В. А.
Address: пр.-т. Макеева 2, 15
Telephone number: +79086395733
Name: Главный технолог
:
Name: Россомахин М. П.
Address: ул. Победы 42, 45
Telephone number: +79080596376
Name: Рутковская Ж. Б.
Address: ул. Луначарского 4, 77
Telephone number: +79507337300
Name: Технический директор
:
Name: Начальник отдела программистов
Заключение
Целью данной работы было показать знания в области моделирования экономических систем и процессов. Она была достигнута при описании комплексной модели экономической системы фирмы «Медиаотражение».
При работе использовалась инструментальная система ARIS 6.23, которая дала возможность отразить различные аспекты, описываемой организации. Она позволила с помощью «Организационной диаграммы» более наглядно рассмотреть организационную структуру, нежели это описано в положении об организационной структуре. С помощью «Модели технических терминов» структура предложения становится более понятной. В модели «Карта знаний» представлены знания и какой процент этих знаний должны иметь программисты. Также инструментальная система ARIS 6.23 позволила описать технические ресурсы, используемые в результате предоставления услуг, цели, которым следует фирма, функциональные потоки, информационные потоки.
При помощи «Событийной цепочки процесса» можно оценить процесс реализации услуг, который был описан в данной диаграмме. Благодаря этой модели можно выявить все минусы и предложить пути решения по их устранению.
Благодаря «ARIS Semantic Check» возможно проверить соответствие моделей всем правилам структуры, «ARIS Chart» — обеспечивает эффективный анализ информации, заложенной в моделях, и их взаимосвязей.
После построения моделей можно использовать еще одну функциональность «ARIS Toolset» –– анимацию, которая особенно удобна для процессно-ориентированнного обучения. При использовании анимации модель БП можно представить в динамике и проанализировать такие параметры БП, как время и стоимость выполнения.
Необходимым модулем ARIS 6.23 является «ARIS Script Editor», который позволяет создавать собственные скрипты отчетов, соответствующие потребностям компании, в дополнение к скриптам, включенным в пакет ARIS.
Проанализировав деятельность фирмы «Медиаотражение» с помощью вышеперечисленных методов можно сделать вывод, о том что предприятию необходимо развиваться, искоренять старые устои и пересмотреть свои БП, упростить их и удешевить.

Приложение №1. Семантическая проверка диаграмм
Приложение №1.1. Организационная диаграмма
Отчет о семантической проверке диаграммы с ошибками.
ARIS Semantic Check
Server: local
Database: New Database
User: system
Rule: Connections between two different objects
Description: This rule, valid for all model types, checks whether all connections in the selected models always connect two different object occurrences. A connection between two occurrences of the same object definition will also be displayed as invalid.
The following objects have a connection relationship to themselves:
Checked model Object name Object type
Check produced no errors.
Connections between two different objects
Rule: No objects without connections may exist
Description: This rule, valid for all model types, checks a model to see if there are object occurrences without connections to other occurrences. Each object in a model must have one or more predecessors and/or successors.
The following objects have no connections to other objects:
Checked model Object name Object type
Check produced no errors.
No objects without connections may exist
Rule: Only one root possible
Description: This rule checks whether hierarchies within the model contain more than one object occurrence of a structurally relevant object type which does not have an incoming connection of a structurally relevant relationship type.
The following models have more than one root:
Checked model Type
Check produced no errors.
Only one root possible
Rule: Each object may have only one direct predecessor
Description: This rule checks whether a hierarchy of the model contains an object occurrence that has two or more superior objects, i.e. more than one incoming connection of a structurally relevant relationship type.
The following objects have more than one direct predecessor:
Checked model Incorrect object Object type
Check produced no errors.
Each object may have only one direct predecessor
Rule: Only one connection is allowed between two objects
Description: This rule checks whether a tree contains two object occurrences which are connected to each other by two or more connections (in the same direction) of a structurally relevant connection type.
The following objects are linked by more than one connection in the same direction:
Checked model Source object Target object
Check produced no errors.
Only one connection is allowed between two objects
Rule: All outgoing connections of an object must be of the same type
Description: This rule checks whether all outgoing structurally relevant connections of an object of a structurally relevant object type, are of the same type.
The following objects have outgoing connections of different types:
Checked model Incorrect object Object type
Check produced no errors.
All outgoing connections of an object must be of the same type
Rule: All connections in a model must be of the same type
Description: This rule checks whether a hierarchy model contains object occurrences of a structurally relevant object type that were linked by connections of different structurally relevant relationship types.
Connections of another relationship type were found between the following objects:
Checked model Source object Target object
1. Организационная диаграмма ООО Консалтинг-юридическая фирма «Налоговые консультации» (Organizational unit) Аудитор (Position)
1. Организационная диаграмма Бухгалтер (Position)
1. Организационная диаграмма Юрист (Position)
All connections in a model must be of the same type
Rule/Models No. 1
1. Connections between two different objects 0
2. No objects without connections may exist 0
3. Only one root possible 0
4. Each object may have only one direct predecessor 0
5. Only one connection is allowed between two objects 0
6. All outgoing connections of an object must be of the same type 0
7. All connections in a model must be of the same type 3
Statistics — Rules
Models No. Name Type Group
1 Организационная диаграмма Organizational chart \Main Group
Statistics — Models
Отчет о семантической проверке исправленной диаграммы.
ARIS Semantic Check
Server: local
Database: New Database
User: system
Rule: Connections between two different objects
Description: This rule, valid for all model types, checks whether all connections in the selected models always connect two different object occurrences. A connection between two occurrences of the same object definition will also be displayed as invalid.
The following objects have a connection relationship to themselves:
Checked model Object name Object type
Check produced no errors.
Connections between two different objects
Rule: No objects without connections may exist
Description: This rule, valid for all model types, checks a model to see if there are object occurrences without connections to other occurrences. Each object in a model must have one or more predecessors and/or successors.
The following objects have no connections to other objects:
Checked model Object name Object type
Check produced no errors.
No objects without connections may exist
Rule: Only one root possible
Description: This rule checks whether hierarchies within the model contain more than one object occurrence of a structurally relevant object type which does not have an incoming connection of a structurally relevant relationship type.
The following models have more than one root:
Checked model Type
Check produced no errors.
Only one root possible
Rule: Each object may have only one direct predecessor
Description: This rule checks whether a hierarchy of the model contains an object occurrence that has two or more superior objects, i.e. more than one incoming connection of a structurally relevant relationship type.
The following objects have more than one direct predecessor:
Checked model Incorrect object Object type
Check produced no errors.
Each object may have only one direct predecessor
Rule: Only one connection is allowed between two objects
Description: This rule checks whether a tree contains two object occurrences which are connected to each other by two or more connections (in the same direction) of a structurally relevant connection type.
The following objects are linked by more than one connection in the same direction:
Checked model Source object Target object
Check produced no errors.
Only one connection is allowed between two objects
Rule: All outgoing connections of an object must be of the same type
Description: This rule checks whether all outgoing structurally relevant connections of an object of a structurally relevant object type, are of the same type.
The following objects have outgoing connections of different types:
Checked model Incorrect object Object type
Check produced no errors.
All outgoing connections of an object must be of the same type
Rule: All connections in a model must be of the same type
Description: This rule checks whether a hierarchy model contains object occurrences of a structurally relevant object type that were linked by connections of different structurally relevant relationship types.
Connections of another relationship type were found between the following objects:
Checked model Source object Target object
Check produced no errors.
All connections in a model must be of the same type
Rule/Models No. 1
1. Connections between two different objects 0
2. No objects without connections may exist 0
3. Only one root possible 0
4. Each object may have only one direct predecessor 0
5. Only one connection is allowed between two objects 0
6. All outgoing connections of an object must be of the same type 0
7. All connections in a model must be of the same type 0
Statistics — Rules
Models No. Name Type Group
1 Variant of Организационная диаграмма Organizational chart \Main Group
Statistics — Models
Приложение №1.2. Модель технических терминов
Диаграмма с ошибками.
Исправленная диаграмма.

Отчет о семантической проверке диаграммы с ошибками.
ARIS Semantic Check
Server: local
Database: New Database
User: system
Rule: Connections between two different objects
Description: This rule, valid for all model types, checks whether all connections in the selected models always connect two different object occurrences. A connection between two occurrences of the same object definition will also be displayed as invalid.
The following objects have a connection relationship to themselves:
Checked model Object name Object type
Check produced no errors.
Connections between two different objects
Rule: No objects without connections may exist
Description: This rule, valid for all model types, checks a model to see if there are object occurrences without connections to other occurrences. Each object in a model must have one or more predecessors and/or successors.
The following objects have no connections to other objects:
Checked model Object name Object type
1. Интернет-проект «Замороженные» Technical term
No objects without connections may exist
Rule: Only one root possible
Description: This rule checks whether hierarchies within the model contain more than one object occurrence of a structurally relevant object type which does not have an incoming connection of a structurally relevant relationship type.
The following models have more than one root:
Checked model Type
Check produced no errors.
Only one root possible
Rule: Each object may have only one direct predecessor
Description: This rule checks whether a hierarchy of the model contains an object occurrence that has two or more superior objects, i.e. more than one incoming connection of a structurally relevant relationship type.
The following objects have more than one direct predecessor:
Checked model Incorrect object Object type
Check produced no errors.
Each object may have only one direct predecessor
Rule: Only one connection is allowed between two objects
Description: This rule checks whether a tree contains two object occurrences which are connected to each other by two or more connections (in the same direction) of a structurally relevant connection type.
The following objects are linked by more than one connection in the same direction:
Checked model Source object Target object
Check produced no errors.
Only one connection is allowed between two objects
Rule: All outgoing connections of an object must be of the same type
Description: This rule checks whether all outgoing structurally relevant connections of an object of a structurally relevant object type, are of the same type.
The following objects have outgoing connections of different types:
Checked model Incorrect object Object type
Check produced no errors.
All outgoing connections of an object must be of the same type
Rule: All connections in a model must be of the same type
Description: This rule checks whether a hierarchy model contains object occurrences of a structurally relevant object type that were linked by connections of different structurally relevant relationship types.
Connections of another relationship type were found between the following objects:
Checked model Source object Target object
Check produced no errors.
All connections in a model must be of the same type
Rule/Models No. 1
1. Connections between two different objects 0
2. No objects without connections may exist 1
3. Only one root possible 0
4. Each object may have only one direct predecessor 0
5. Only one connection is allowed between two objects 0
6. All outgoing connections of an object must be of the same type 0
7. All connections in a model must be of the same type 0
Statistics — Rules
Models No. Name Type Group
1 Интернет-проект Technical terms model \Main Group
Statistics — Models

Отчет о семантической проверке исправленной диаграммы.
ARIS Semantic Check
Server: local
Database: New Database
User: system
Rule: Connections between two different objects
Description: This rule, valid for all model types, checks whether all connections in the selected models always connect two different object occurrences. A connection between two occurrences of the same object definition will also be displayed as invalid.
The following objects have a connection relationship to themselves:
Checked model Object name Object type
Check produced no errors.
Connections between two different objects
Rule: No objects without connections may exist
Description: This rule, valid for all model types, checks a model to see if there are object occurrences without connections to other occurrences. Each object in a model must have one or more predecessors and/or successors.
The following objects have no connections to other objects:
Checked model Object name Object type
Check produced no errors.
No objects without connections may exist
Rule: Only one root possible
Description: This rule checks whether hierarchies within the model contain more than one object occurrence of a structurally relevant object type which does not have an incoming connection of a structurally relevant relationship type.
The following models have more than one root:
Checked model Type
Check produced no errors.
Only one root possible
Rule: Each object may have only one direct predecessor
Description: This rule checks whether a hierarchy of the model contains an object occurrence that has two or more superior objects, i.e. more than one incoming connection of a structurally relevant relationship type.
The following objects have more than one direct predecessor:
Checked model Incorrect object Object type
Check produced no errors.
Each object may have only one direct predecessor
Rule: Only one connection is allowed between two objects
Description: This rule checks whether a tree contains two object occurrences which are connected to each other by two or more connections (in the same direction) of a structurally relevant connection type.
The following objects are linked by more than one connection in the same direction:
Checked model Source object Target object
Check produced no errors.
Only one connection is allowed between two objects
Rule: All outgoing connections of an object must be of the same type
Description: This rule checks whether all outgoing structurally relevant connections of an object of a structurally relevant object type, are of the same type.
The following objects have outgoing connections of different types:
Checked model Incorrect object Object type
Check produced no errors.
All outgoing connections of an object must be of the same type
Rule: All connections in a model must be of the same type
Description: This rule checks whether a hierarchy model contains object occurrences of a structurally relevant object type that were linked by connections of different structurally relevant relationship types.
Connections of another relationship type were found between the following objects:
Checked model Source object Target object
Check produced no errors.
All connections in a model must be of the same type
Rule/Models No. 1
1. Connections between two different objects 0
2. No objects without connections may exist 0
3. Only one root possible 0
4. Each object may have only one direct predecessor 0
5. Only one connection is allowed between two objects 0
6. All outgoing connections of an object must be of the same type 0
7. All connections in a model must be of the same type 0
Statistics — Rules
Models No. Name Type Group
1 Интернет-проект Technical terms model \Main Group
Statistics – Models

Приложение №1.3. eEPC
Исправленная диаграмма

Отчет о семантической проверке диаграммы с ошибками.
ARIS Semantic Check
Server: local
Database: New Database
User: system
Rule: Connections between two different objects
Description: This rule, valid for all model types, checks whether all connections in the selected models always connect two different object occurrences. A connection between two occurrences of the same object definition will also be displayed as invalid.
The following objects have a connection relationship to themselves:
Checked model Object name Object type
Check produced no errors.
Connections between two different objects
Rule: No objects without connections may exist
Description: This rule, valid for all model types, checks a model to see if there are object occurrences without connections to other occurrences. Each object in a model must have one or more predecessors and/or successors.
The following objects have no connections to other objects:
Checked model Object name Object type
Check produced no errors.
No objects without connections may exist
Rule: Each path must begin and end with an event
Description: This rule checks whether all paths of a selected model begin and end with an object occurrence of the event type.
The following start or target objects are not events:
Checked model Object name Object type
1. Получение заказа Получение заказа Function
Each path must begin and end with an event
Rule: Number of outgoing or incoming connections to the connector
Description: At occurrence level, this rule checks whether at each simple operator of the selected model there is exactly one incoming and a minimum of two outgoing connections or a minimum of two incoming and exactly one outgoing connection.
The number of incoming and outgoing connections is not correct for the following operators:
Checked model Object name Object type
Check produced no errors.
Number of outgoing or incoming connections to the connector
Rule: All functions/events have only one incoming/outgoing connection
Description: This rule checks whether all functions and events of a selected model have a maximum of one incoming or outgoing connection.
The following functions and events have more than one incoming or outgoing connection:
Checked model Object name Object type
1. Получение заказа Разработка технического задания Function
All functions/events have only one incoming/outgoing connection
Rule: No XOR/OR after event possible
Description: This rule checks whether an opening OR or XOR operator (distribution list) was created within a process after events. These events are reported as rule violations in the Semantic Check result.
The following events have an OR or an XOR operator as successor:
Checked model Event Following operator
1. Получение заказа Концепция разработана XOR rule
Техническое задание согласовано XOR rule
No XOR/OR after event possible
Rule: Order at the operator must be preserved
Description: At occurrence level, this rule checks whether the set of preceding object types and the set of following object types for objects of the «rule» type do not overlap. When, for example, all incoming connections come from events, then all outgoing connections may only lead to functions, and vice versa.
The following operators have the same object types both as predecessors and as succesors:
Checked model Object name Object type
1. Получение заказа Получение технического задания у заказчика (predecessor) Function
Согласовано (predecessor) Event
OR rule Rule
Начало работ (successor) Function
Техническое задание согласовано (predecessor) Event
XOR rule Rule
Согласовано (successor) Event
Не согласовано (successor) Event
Концепция разработана (predecessor) Event
XOR rule Rule
Нет готового технического задания (successor) Event
Есть готовое техническое задание (successor) Event
Order at the operator must be preserved
Rule/Models No. 1
1. Connections between two different objects 0
2. No objects without connections may exist 0
3. Each path must begin and end with an event 1
4. Number of outgoing or incoming connections to the connector 0
5. All functions/events have only one incoming/outgoing connection 1
6. No XOR/OR after event possible 2
7. Order at the operator must be preserved 3
Statistics — Rules
Models No. Name Type Group
1 Получение заказа eEPC \Main Group
Statistics — Models
Отчет о семантической проверке исправленной eEPC диаграммы.
ARIS Semantic Check
Server: local
Database: New Database
User: system
Rule: Connections between two different objects
Description: This rule, valid for all model types, checks whether all connections in the selected models always connect two different object occurrences. A connection between two occurrences of the same object definition will also be displayed as invalid.
The following objects have a connection relationship to themselves:
Checked model Object name Object type
Check produced no errors.
Connections between two different objects
Rule: No objects without connections may exist
Description: This rule, valid for all model types, checks a model to see if there are object occurrences without connections to other occurrences. Each object in a model must have one or more predecessors and/or successors.
The following objects have no connections to other objects:
Checked model Object name Object type
Check produced no errors.
No objects without connections may exist
Rule: Each path must begin and end with an event
Description: This rule checks whether all paths of a selected model begin and end with an object occurrence of the event type.
The following start or target objects are not events:
Checked model Object name Object type
Check produced no errors.
Each path must begin and end with an event
Rule: Number of outgoing or incoming connections to the connector
Description: At occurrence level, this rule checks whether at each simple operator of the selected model there is exactly one incoming and a minimum of two outgoing connections or a minimum of two incoming and exactly one outgoing connection.
The number of incoming and outgoing connections is not correct for the following operators:
Checked model Object name Object type
Check produced no errors.
Number of outgoing or incoming connections to the connector
Rule: All functions/events have only one incoming/outgoing connection
Description: This rule checks whether all functions and events of a selected model have a maximum of one incoming or outgoing connection.
The following functions and events have more than one incoming or outgoing connection:
Checked model Object name Object type
Check produced no errors.
All functions/events have only one incoming/outgoing connection
Rule: No XOR/OR after event possible
Description: This rule checks whether an opening OR or XOR operator (distribution list) was created within a process after events. These events are reported as rule violations in the Semantic Check result.
The following events have an OR or an XOR operator as successor:
Checked model Event Following operator
Check produced no errors.
No XOR/OR after event possible
Rule: Order at the operator must be preserved
Description: At occurrence level, this rule checks whether the set of preceding object types and the set of following object types for objects of the «rule» type do not overlap. When, for example, all incoming connections come from events, then all outgoing connections may only lead to functions, and vice versa.
The following operators have the same object types both as predecessors and as succesors:
Checked model Object name Object type
Check produced no errors.
Order at the operator must be preserved
Rule/Models No. 1
1. Connections between two different objects 0
2. No objects without connections may exist 0
3. Each path must begin and end with an event 0
4. Number of outgoing or incoming connections to the connector 0
5. All functions/events have only one incoming/outgoing connection 0
6. No XOR/OR after event possible 0
7. Order at the operator must be preserved 0
Statistics — Rules
Models No. Name Type Group
1 Получение заказа(1) eEPC \Main Group
Statistics — Models

Приложение № 2. Проверка на адекватность моделей.
Приложение № 2.1. Existence Rules.
Отчет о семантической проверке по правилам существования
ARIS Semantic Check
Server: local
Database: New Database
User: system
Rule: Organizational unit from eEPC in organizational chart
Description: All objects of the «Organizational unit» type created in the eEPC models to be examined have to be illustrated in the selected organizational charts.
The following objects must have at least one occurrence in at least one of the named models:
Checked model Object Incorrect target model
Получение заказа(1) Менеджмент Организационная диаграмма
Organizational unit from eEPC in organizational chart
Rule: Position from eEPC in organizational chart
Description: All objects of the «Position» type created in the eEPC models to be examined have to be illustrated in the selected organizational charts.
The following objects must have at least one occurrence in at least one of the named models:
Checked model Object Incorrect target model
Check produced no errors.
Position from eEPC in organizational chart
Rule: Person from eEPC in organizational chart
Description: All objects of the «Person» type created in the eEPC models to be examined have to be illustrated in the selected organizational charts.
The following objects must have at least one occurrence in at least one of the named models:
Checked model Object Incorrect target model
Получение заказа(1) Заказчик Организационная диаграмма
Юрист Организационная диаграмма
Person from eEPC in organizational chart
Rule: Group from eEPC in organizational chart
Description: All objects of the «Group» type created in the eEPC models to be examined have to be illustrated in the selected organizational charts.
The selected models could not be checked with the rule.
Rule: Location from eEPC in organizational chart
Description: Each location in an eEPC has to exist in the organizational chart, too.
The selected models could not be checked with the rule.
Rule/Models No. 1
1. Organizational unit from eEPC in organizational chart 1
2. Position from eEPC in organizational chart 0
3. Person from eEPC in organizational chart 2
4. Group from eEPC in organizational chart —
5. Location from eEPC in organizational chart —
Statistics — Rules
Models No. Name Type Group
1 Получение заказа(1) eEPC \Main Group
Statistics – Models
Приложение № 2.2. Allocation Rules.
Отчет о семантической проверки по правилам взаимосвязи объектов для eEPC (Allocation Rules for eEPC)
ARIS Semantic Check
Server: local
Database: New Database
User: system
Rule: Function is executed by organizational unit (1:1)
Description: According to this rule, each function can be executed by exactly one organizational unit.
The following objects have fewer than 1 or more than 1 assigned object(s) of type Organizational unit than is permitted:
Checked model Object Incorrect relationship
Получение заказа(1) Есть техническое задание? less than 1
Начало работ less than 1
Подписание договора less than 1
Получение заказа less than 1
Получение технического задания у заказчика less than 1
Разработка концепции less than 1
Разработка технического задания more than 1
Согласование технического задания с заказчиком less than 1
Function is executed by organizational unit (1:1)
Rule: Function is executed by position (1:3)
Description: This rule checks whether a function is executed by at least 1 and at most 3 organizational units.
The following objects have fewer than 1 or more than 3 assigned object(s) of type Position than is permitted:
Checked model Object Incorrect relationship
Получение заказа(1) Есть техническое задание? less than 1
Начало работ less than 1
Подписание договора less than 1
Получение заказа less than 1
Разработка концепции less than 1
Разработка технического задания less than 1
Function is executed by position (1:3)
Rule/Models No. 1
1. Function is executed by organizational unit (1:1) 8
2. Function is executed by position (1:3) 6
Statistics — Rules
Models No. Name Type Group
1 Получение заказа(1) eEPC \Main Group
Statistics – Models

Приложение № 2.3. ARIS Analysis
Информационные разрывы.
ARIS Analysis:
Created: 28.06.2009 11:15:12
Server: local
Database: New Database
User: system
File: Analysis1.xls
Analysis: Evaluation of media breaks in the process
Models:
1.) \Main Group\Получение заказа(1) (eEPC)
1.) Model
Number of functions 8
Collectively associated information carriers 2
Input information carrier 0
Output information carrier 2
Functions with at least 1 input information carrier 0
Functions with at least 1 output information carrier 2
Functions with at least 1 input information carrier and 1 output information carrier 0
Functions with different input and output information carriers 0
Number of function transitions 1
Function transitions with media breaks 1
Relationship between media breaks and function transitions 1
Media breaks in the process

Организационные разрывы
ARIS Analysis:
Created: 28.06.2009 11:17:15
Server: local
Database: New Database
User: system
File: Analysis2.xls
Analysis: Evaluation of organizational change in the process
Models:
1.) \Main Group\Получение заказа(1) (eEPC)
1.) Model
Number of functions 8
Functions with organizational assignment 4
Number of function transitions 3
Total assigned organizational elements 6
Organizational units 4
Groups 0
Persons 1
Positions 1
Employees 0
minimum number of organization changes 3
relationship beetween minimum organization changes/function transitions 1
maximum number of organization changes 3
relationship beetween maximum organization changes/function transitions 1
Organizational change in the process
Список используемой литературы
1. Курс лекций по дисциплине «Анализ и оптимизация бизнес-процессов».
2. Войнов И.В., Пудовкина С.Г., Телегин А.И. Моделирование экономических систем и процессов. Опыт построения ARIS-моделей: Монография. — Челябинск: Изд. ЮУрГУ, 2002. – 392 с.
3. Каменова М., Громов А., Ферапонтов М., Шматалюк А. Моделирование бизнеса. Методология ARIS. М.: ООО «Издательство «Серебряные нити», 2001. – 327 с.